This invention relates to an information processing method and apparatus and, more particularly, to an information processing method and apparatus for managing persistent data, the state of which is maintained even after execution of an application or the like, as well as transient data, the existence whereof vanishes with the end of execution of an application or the like.
Two types of data generally are mixed in database applications. One type is persistent data located in the database and shared by a plurality of applications, and the other type of data is transient data, which exists only during execution of the database application and vanishes with the end of the application.
With regard to persistent data, the conventional practice is to use transactions as a mechanism for updating the data while assuring its consistency. In an application, a transaction is started by a transaction-start command. It is possible to refer to the persistent data and to update the same during execution of the transaction. There are two ways to terminate transactions. One is a commit operation in which the content of the change during the transaction is reflected in the database, and the other is an abort operation in which the content of the change is discarded without updating the database.
Furthermore, the abort of a transaction includes a case in which abort is started internally by the application itself and a case in which abort is started externally in order to overcome a deadlock. In the case where the abort operation is started externally, a method is often used in which the burden upon the application for dealing with the abort is alleviated by implementing retry automatically.
In the prior art, the consistency of persistent data in the abort and retry of a transaction is assured, but undesirable side effects occur with regard to transient data. For example, if, in processing for counting up the number of elements' in a set of certain persistent data, the number of elements is transient data, a side effect occurs in which some of the elements are counted up redundantly in response to the occurrence of transaction retry unless the number of elements is initialized at the time of an abort. Generally, in order to prevent side effects in transient data at the time of an abort, it is necessary for the application to sense the abort of a transaction and to reinitialize the transient data appropriately. As a result, the burden involved in developing applications is greater, and often the result is erroneous operation and lower reliability.
There are also instances in which use is made of the very side effect brought about by abort of a transaction. For example, in a case where the number of retries of a transaction is counted, the counter itself becomes transient data, but of course initializing such transient data when the transaction is retried makes it impossible to attain the original objective of counting the retries. Accordingly, in order to handle transient data in a transaction, there is a necessity for means for distinguishing between transient data to be initialized at retry of a transaction and transient data not to be so initialized.